home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Ian & Stuart's Australian Mac: Not for Sale
/
Another.not.for.sale (Australia).iso
/
fade into you
/
being there
/
Rants
/
Morningstar
/
ppp.faq-3.11
< prev
next >
Wrap
Text File
|
1994-08-19
|
71KB
|
1,636 lines
Archive-name: ppp-faq/part1
Version: $Revision: 3.11 $
Last-modified: $Date: 94/05/30 20:10:10 $
URL: http://cs.uni-bonn.de/ppp/part1.html
1. LETTER FROM THE EDITOR
Important Changes
Introduction
Information wanted
1.0 Important Changes
corrected a typo in 5.5.1 (AmigaNOS mailing list address)
1.1 Introduction
I took the Information in Ed Vielmetti's FAQ files, my personal
experience, and lots of stuff from comp.protocols.ppp, and built a new
document. Later, lots of people contributed at one or the other place.
This document will be reposted fortnightly, as soon as it is fairly
stable, and weekly till then. Changed sections should be marked in the
Table of Contents with a ! or + for something got added or - for
something got deleted.
1.2 Information Wanted
If you have experience with anything mentioned here, or know of newer
versions, or of versions of software for other hardware/OS, or ... send
me mail. I'll include it and possibly mention your name, if you don't
express otherwise.
The last paragraph applies explicitly to the authors themselves! Keep me
informed, please.
Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
2. WHAT IS PPP?
Introduction
PPP features which may or may not be present
PPP glossary
PPP-relevant RFC's
2.1 Introduction
PPP is the Internet Standard for transmission of IP packets over serial
lines. PPP supports async and sync lines. For a general discussion of
PPP, and of the PPP vs. SLIP question, look at the paper
ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (paper) and
sug91-cheapIP.shar.Z (overhead projector slides)
2.2 PPP features which may or may not be present
Above and beyond compatibility with basic PPP framing, note whether the
software implements the following features. Not all features are needed
or even desired in every product. Please note also that not every free
or commercial product description in this document has a complete list
of all features includes.
demand-dial Bring up a PPP interface and dial the phone when
packets are queued for delivery; bring the
interface down after some period of inactivity.
redial (For lack of a better term)
Bring up a PPP interface whenever it goes down,
to keep a line up. (sometimes called camping)
camping (on a line) see redial
scripting Negotiate through a series of prompts or
intermediate connections to bring up a PPP link,
much like the sequence of events used to bring
up a UUCP link.
parallel Configure several PPP lines to the same
destination and do load sharing between them.
(Not standardized, usually only seen in SLIP
implementations, noted there as "parallel-slip".)
filtering Select which packets to send down a link or
whether to bring up a "demand-dial" link based
on IP or TCP packet type or TOS, e.g. don't dial
the phone for ICMP ping packets.
header compression TCP header compression according to RFC1144.
Marginally useful on high speed lines, essential
for low speed lines.
server Accept incoming PPP connections, which might well
also include doing the right things with
routing.
tunneling Build a virtual network over a PPP link across a
TCP stream through an existing IP network.
extra escaping Byte-stuffing characters outside the negotiated
asyncmap, configurable in advance but not
negotiable.
2.3 PPP glossary
Every new technology breeds its own set of acronyms. PPP is no
different. Here is a glossary of sorts.
ack Acknowledgement.
AO Active open [state diagram] (no lonter part of the
FSM as of RFC1331)
C Close [state diagram]
CHAP Challenge-Handshake Authentication Protocol
(RFC1334)
D Lower layer down [state diagram]
DES Data Encryption Standard
DNA Digital Network Architecture
IETF Internet Engineering Task Force.
IP Internet Protocol
IPCP IP Control Protocol.
IPX Internetwork Packet Exchange (Novell's networking
stack)
FCS Frame Check Sequence [X.25]
FSA Finite State Automaton
FSM Finite State Maschine
LCP Link Control Protocol.
LQR Link Quality Report.
MD4 MD4 digital signature algorithm
MD5 MD5 digital signature algorithm
MRU Maximum Receive Unit
MTU Maximum Transmission Unit
nak Negative Acknowledgement
NCP Network Control Protocol.
NRZ Non-Return to Zero bit encoding. (SYNC ppp default
because of
availability)
NRZI Non-Return to Zero Inverted bit encoding. (SYNC ppp
preferred
alternative to NRZ)
OSI Open Systems Interconnect
PAP Password Authentication Protocol (RFC1334)
PDU Protocol Data Unit (i.e., packet)
PO Passive open [no longer part of state diagram]
PPP Point to Point Protocol (
RFC1548 /
RFC1549,
1332,
1333,
1334,
1551,
1376,
1377,
1378)
RCA Receive Configure-Ack [state diagram]
RCJ Receive Code-Reject [state diagram]
RCN Receive Configure-Nak or -Reject [state diagram]
RCR+ Receive good Configure-Request [state diagram]
RER Receive Echo-Request [no longer part of state
diagram]
RFC Request for Comments (internet standard)
RTA Receive Terminate-Ack [state diagram]
RTR Receive Terminate-Request [state diagram]
RUC Receive unknown code [state diagram]
sca Send Configure-Ack [state diagram]
scj Send Code-Reject [state diagram]
scn Send Configure-Nak or -Reject [state diagram]
scr Send Configure-Request [state diagram]
ser Send Echo-Reply [no longer part of state diagram]
sta Send Terminate-Ack [state diagram]
str Send Terminate-Request [state diagram]
ST-II Stream Protocol
TO+ Timeout with counter > 0 [state diagram]
TO- Timeout with counter expired [state diagram]
VJ Van Jacobson (RFC1144 header compression algorithm)
XNS Xerox Network Services
2.4 PPP relevant RFCs
Here's a list with descriptions. Note some of these are obsolete. You
might also want to search for recent RFCs or internet drafts in an
up-to-date RFC archive.
1570 Simpson, W.,ed. PPP LCP Extensions. 1994 January;
18 p. (Format: TXT=35719 bytes) (Updates RFC 1548)
1553 Mathur, S.; Lewis, M. Compressing IPX Headers Over
WAN Media (CIPX). 1993 December; 23 p. (Format:
TXT=47450 bytes)
1552 Simpson, W. The PPP Internetwork Packet Exchange
Control Protocol (IPXCP). 1993 December; 14 p.
(Format: TXT=29174 bytes)
1551 Allen, M. Novell IPX Over Various WAN Media
(IPXWAN). 1993 December; 22 p. (Format: TXT=54210
bytes) (Obsoletes RFC 1362)
1549 Simpson, W.,ed. PPP in HDLC Framing. 1993
December; 18 p. (Format: TXT=36353 bytes)
1548 Simpson, W. The Point-to-Point Protocol (PPP).
1993 December; 53 p. (Format: TXT=111638 bytes)
(Obsoletes RFC 1331; Updated by RFC 1570)
1547 Perkins, D. Requirements for an Internet Standard
Point-to-Point Protocol. 1993 December; 21 p.
(Format: TXT=49811 bytes)
1378 PPP AppleTalk Control Protocol (ATCP). Parker, B.
1992 November; 16 p. (Format: TXT=28496 bytes)
1377 PPP OSI Network Layer Control Protocol (OSINLCP).
Katz, D. 1992 November; 10 p. (Format: TXT=22109
bytes)
1376 PPP DECnet Phase IV Control Protocol (DNCP).
Senum, S.J. 1992 November; 6 p. (Format: TXT=12448
bytes)
1362 Allen, M. Novell IPX Over Various WAN Media
(IPXWAN). 1992 September; 18 p. (Format: TXT=30220
bytes)
1334 PPP authentication protocols. Lloyd, B.; Simpson,
W.A. 1992 October; 16 p. (Format: TXT=33248 bytes)
1333 PPP link quality monitoring. Simpson, W.A. 1992
May; 15 p. (Format: TXT=29965 bytes)
1332 PPP Internet Protocol Control Protocol (IPCP).
McGregor, G. 1992 May; 12 p. (Format: TXT=17613
bytes) (Obsoletes RFC1172)
1331 Point-to-Point Protocol (PPP) for the transmission
of multi-protocol datagrams over point-to-point
links. Simpson, W.A. 1992 May; 66 p. (Format:
TXT=129892 bytes) (Obsoletes RFC1171, RFC1172;
obsoleted by RFC 1548)
1220 Point-to-Point Protocol extensions for bridging.
Baker, F.,ed. 1991 April; 18 p. (Format: TXT=38165
bytes)
1172 Point-to-Point Protocol (PPP) initial
configuration options. Perkins, D.; Hobby, R. 1990
July; 38 p. (Format: TXT=76132 bytes) (Obsoleted by
RFC1331, RFC1332)
1171 Point-to-Point Protocol for the transmission of
multi-protocol datagrams over Point-to-Point links.
Perkins, D. 1990 July; 48 p. (Format: TXT=92321
bytes) (Obsoletes RFC1134; Obsoleted by RFC1331)
1134 Point-to-Point Protocol: A proposal for
multi-protocol transmission of datagrams over
Point-to-Point links. Perkins, D. 1989 November;
38 p. (Format: TXT=87352 bytes) (Obsoleted by
RFC1171)
1144 Compressing TCP/IP headers for low-speed serial
links. Jacobson, V. 1990 February; 43 p.
(Format: TXT=120959 PS=534729 bytes)
In comp.protocols.ppp (Message-ID:
<BOB.92Dec3145948@volitans.MorningStar.Com>)
bob@MorningStar.Com (Bob Sutterfield)
wrote :
All of 1134, 1171, and 1172 (and 1055, for that matter :-) have been
obsoleted. They're interesting only if you want to debug a connection
with an ancient PPP implementation, and you're wondering why (e.g.) it
asked you for IPCP option 2 with a length of only 4, and
Compression-Type 0x0037.
(There's a lot of that still running around - be careful out there.)
3. HOW TO (CONFIGURATION RECIPES)
complain about missing or incorrect information in the FAQ list
connect a single host to a network without needing a new subnet.
configure free ppp for sun to interoperate with MacPPP 1.0
get SCO TCP 1.2 to connect to Ethernet LANs by a PPP link
use PPP through a X.25 PAD
use SunLINK PPP 1.0 to a CISCO
through a sync line
use MacPPP 2.0.1 on non-US
System 6 MACs
3.0 complain about missing or incorrect information in the FAQ list
E-mail to
ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis)
and add information I'll need to think about it. That is:
In case of incorrect information, send me the correct information
and the source of it.
In case of missing information, send me the information which is
missing and the source of it.
3.1 connect a single host to a network without needing a new subnet.
If you have only one single machine on the other side, the easiest way
is to give it a IP address belonging to the local ethernet/IP subnet,
and to tell the ppp gateway machine to advertise (proxy arp) its own
ethernet address as the other machines'. Works like a charm here. Of
course, for a large group or complicated network on the other side, you
would get more management problems.
On the gateway do:
arp -s othermachinesipaddress myownethernetaddress permanent public
ifconfig pppNUMBER myipaddress othermachinesipaddress [other params] up
on remote machine:
ifconfig pppNUMBER gatewaysipaddress [other params] up
route add default gatewaysipaddress 1
pppNUMBER might be spelled as dpNUMBER for dialup IP.
Of course, if you use routeing daemons, you could also propagate the
route via routed / gated etc. to other machines, but it's more painful
because every machine has to do it (and might choose not to do it), and
every machine doing IP on a Ethernet HAS to talk arp.
On intermittently connected demand-dialed links, you may need to edit
/etc/gateways to define the destination of the PPP or SLIP connection as
a "passive" link. Otherwise, routed will remove routes from the
kernel's routing table that use that link, because it won't hear RIPs
coming from hosts or routers across the wire. Since it doesn't hear
anything from hosts or routers on the far side of the wire, routed
assumes that the link is dead forever.
ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
3.2 configure KA9Q PPP and it's Unix counterpart
Newsgroups: comp.protocols.ppp
From: kim@MorningStar.Com (Kim Toms)
Subject: Re: PPP for DOS? (good info for FAQ)
Date: Wed, 9 Dec 1992 06:26:28 GMT
I have been able to use the ka9q software on my PC to call my Suns at
work. This is available from merit.edu:/pub/ppp/ka9q.zip. I had to tell
our Sun product [that would be Morning Star PPP, see below. I.S.]
"nolqm" in order to prevent it from hanging up because of an lqm
failure, but other than that, I have had no trouble.
Below, I include the configuration I use on my pc. I unpacked the ka9q
distribution into \ka9q. All the configuration files are located there.
I have also been able to use the NCSA telnet packet driver, however, I
could not use ftp with that, so I gave it up some months ago.
Here's what I use on the PC:
In a file called "doit2.bat":
net -d \ka9q dialup.net
In a file called "dialup.net":
ip address 137.175.2.42
attach asy 0x3f8 4 ppp pp0 1024 256 9600
dialer pp0 dialup.ppp
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
route add default pp0
ip ttl 32
tcp mss 1460
tcp window 2920
domain addserver 137.175.2.11
domain suffix MorningStar.Com
domain cache clean on
start echo
start discard
start telnet
start ftp
start finger
start ttylink
In a file called "dialup.ppp":
control down
wait 1000
control up
wait 1000
wait 2000
send "at\r"
wait 3000 "OK"
send "atdt4515016\r"
wait 60000 "login: "
send "<username>\r"
wait 5000 "word:"
wait 1000
send "<password>\r"
3.2.2 CONFIGURE KA9Q PPP (WITH NEW DIALER) AND IT'S UNIX COUNTERPART
deleted, becausy to my knowledge, there is no KA9Q with new dialer and
working PPP.
3.2.3 CONFIGURE JNOS
I have jnos1.08 up and running. [that is, 'version 911229 (WG7J
v1.08)']. For a sample configuration and demonstration of operation,
get the configuration and executable you can ftp from
speckled.mpifr-bonn.mpg.de, user ftp, directory /pub/rhein.de or
/pub/incoming.
ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
3.3 configure NCSA with the merit ppp packet driver and its unix
counterpart
I had at least partial success using the parameters, to the public ppp
for SUNOS (dp-2.3, but I suspect any of dp-2.1 or dp-2.2* or
pppd-1.01beta or ppp-1.1 would have the same behaviour) -ac -pc vjmode
draft. The latter would be called in ppp-1.1 (and up) 'vjmode rfc1331'.
ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
3.4 work BOOTP over protocols such as SLIP or PPP
Newsgroups: comp.protocols.ppp
From: johnson@tigger.jvnc.net (Steven L. Johnson)
Subject: Re: Tech?: BOOTP over SLIP or PPP
Date: Wed, 2 Dec 1992 03:14:37 GMT
[Somebody on the net] writes:
Does anybody know if there is a description of how to work BOOTP over
protocols such as SLIP or PPP. It seems this should work but the problem
is that there is a field in the BOOTP header that contains the physical
layer type, and these numbers are defined as the hardware types for ARP.
Since SLIP and PPP do not use ARP, they do not have numbers.I haven't
looked very far, and would appreciate a pointer to any previous work or
concensus. I've used a type 0 but only with a cisco terminal server. I
don't know if this causes problems on other implementations.
The second problem is that the BOOTP header also contains a field for
the physical layer address (i.e. Ethernet address). PPP and SLIP do not
have an physical layer addresses. What does the BOOTP server have to
base it's IP address suggestion on? It's my understanding that PPP can
itself negotiate the IP address and that this is the preferred method.
If the IP address is included in the bootp request then the remaining
configuration is done based on that IP address and not the hardware
address. With SLIP there isn't this option, so the IP address must be
assigned by knowing the physical port on which the request was received.
Again, I used an address of 0 (with a address length of 0, I think) and
this didn't seem to cause a problem.
On a terminal server that contained only a minimal implementation of
bootp, it was necessary to send two requests. The first request was
satisfied by the terminal server and configured only the IP address. A
subsequent request (that contained the IP address provided by the first
request) was forwarded by the terminal server to a bootp server on the
ethernet and provided the rest of the configuration from a standard
bootptab.
-Steve
3.5 configure free ppp for sun to interoperate with MacPPP 1.0
From: guy@world.std.com (Guy K Hillyer)
Comments-by: Ignatios Souvatzis, marked with [comments... I.S.]
Subject: Success with MacPPP
Date: Wed, 20 Jan 1993 02:02:08 GMT
After many travails, I finally got MacPPP to work for me. This is the
story of how I got it to work. This account is purely anecdotal. I
don't claim to know what is the best configuration, just what worked for
me.
I submit this for the benefit of other poor suckers who might otherwise
spend days getting a Mac/Sun PPP link to work, like I did. I'm a happy
camper now, and thanks to Larry Blunk @ merit.edu for making his
implementation freely available. Now all I need is a T1 line to my
house and I'll be all set.
[I'm not sure MacPPP works on T1 lines, I'm pretty sure the Perkins et
al. PPP doesn't work over T1 lines. I.S.]
After working with the beta release for a while, I picked up the latest
and greatest MacPPP at merit.edu. The file is named
/pub/ppp/macppp1.0.sit.hqx. I don't think there's any big difference
between that and the beta version, but the docs did have two or three
new sentences that helped to clarify matters.
The ppp I'm using on the UNIX side is the one identified as
`Perkins/Clements/Fox/Christy PPP for SunOS' in the comp.protocols.ppp
FAQ. During the course of debugging my connection, I installed the
package identified in that document as dp-2.2, but it behaved in exactly
the same way as the other one did with regard to the problems I was
having, so I only tried it briefly. It has some more advanced
capabilities so I may switch to it in the future, but for now I'm just
glad to have a working configuration.
Mac configuration:
One mistake I made was ignoring the point made in the MacPPP docs
about configuring MacTCP for server addressing. I thought that
"server addressing" implied that the mac would get its IP address
from some kind of server on my network, using RARP or something like
that. I thought that didn't make sense in my situation, so I
configured MacTCP for manual addressing. In fact, I now believe
that "server addressing" means that TCP gets the address from the IP
layer. I'm not an ISO networking model savant, so this
[must be wrong... the IP layer gets its address from the PPP layer,
which can do an address negotiation.]
notion should be taken with a grain of salt.
I also set MacTCP to have a "class C" network address. I think
this only matters for broadcast packets, because it sets the
netmask. Again, I'm treading on thin ice here.
I set the IP addresses in the MacPPP control panel's IPCP
configuration window. This probably isn't necessary, but I wanted
to make sure that I got a particular address. If you set the
addresses on the Mac side, you'll want to specify the addresses and
disable IP address negotiation on the UNIX side ("-ip" option to
ppp).
I first got things working with VJ header compression disabled on
both sides. You may want to try it this way if you have any
trouble. This is set in the IPCP window. If you disable VJ header
compression on the Mac side, you'll want to disable it on the UNIX
side as well ("-vj" option to ppp).
[You probably need only to set it to 'draft'. The configuration
negotiation should do the rest. The only reason you need a 'vjmode'
option is that the format of the configuration option has changed and
the older ones don't understand the format of the aug91draft or
rfc1331 ones (which should be the same) I.S.]
Once I got things working I turned on VJ header compression. It
only worked for me if I selected "draft" mode on the UNIX side
("vjmode draft" option to ppp).
Sun configuration:
I configure the ppp interface like this:
ifconfig ppp0 <Sun's IP addr> <Mac's IP addr> netmask 0xffffff00 do
wn
Then I start ppp like this:
ppp -p vjmode draft -ip <Sun's IP addr>:<Mac's IP addr>
[which is also about the configuration of dp-2.x, on the login line.
You have to specify PPP_OPTIONS=vjmode,draft in the configuration file
for the network interface used by the mac. For ppp-1.1/2.tar.Z, use
'vjmode rfc1331' I.S.]
The "-p" means passive, so the Sun waits for the Mac to start the
handshaking. My experience was that without -p, there was a very
brief window during which the Mac could enter the negotiation, and
if it missed window, then all was lost.
"vjmode draft" means to use the new version of negotiation
specified in the August 1991 Draft RFC for IPCP. This is apparently
the only version MacPPP knows how to deal with. If you've disabled
VJ header compression on the Mac, you should give "-vj" instead.
"-ip" disables IP address negotiation. It probably would work
fine without this; I just haven't tried it that way.
3.6 get SCO TCP 1.2 to connect to Ethernet LANs by a PPP link
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: PPP on SCO between different networks
In article uaa1006@dircon.co.uk (Peter Miles) writes:
I need to set up a UNIX system which is on an ethernet LAN (with
its own IP address), so it can call up a PPP link to another network,
and use a different IP address on the remote network. There's a bug in
SCO TCP 1.2 (but not in 1.1.3) that prevents this scenario with SCO's
PPP, and with any other PPP or SLIP software you might try to use on
your SCO system. You can get the fix from
ftp.morningstar.com:pub/tools/SCO-route-fix, or through SCO's normal
support channels.
3.7 use PPP through a X.25 PAD
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Subject: Re: PPP or SLIP through PAD (X.29/X.25)
Date: Mon, 5 Apr 1993 19:30:17 +0200
Organization: Regionales Rechenzentrum Erlangen, Germany
Does anybody have experience with "tunneling" PPP and SLIP through the
PAD-service (X.29 over X.25)? What I want is to let people dial up their
PAD-service and send their PPP/SLIP packets across the X.25 network into
the PAD-login of my UNIX-machine. This should be possible, but I guess
the PAD-parameter configuration is critical?? Yes, that's of course
possible, because that's the way I use PPP. Use the PAD parameters for
the following settings:
no escape character 1:0
local echo off 2:0
flow/control: RTS/CTS 5:2 (this is perhaps not a standard X.3
parameter)
PAD should not react on XON/XOFF signals 12:0
Other important values might be 3:0 4:1 9:0 10:0 13:0 14:0 15:0.
You need a PAD that supports CTS/RTS flow control, because I don't know
about PPP software that supports XON/XOFF (although this would be
possible with the right async map).
Markus
3.8 use SunLINK PPP 1.0 to a CISCO through a sync line
To connect successfully a Sun running 4.1.x and Sunlink PPP 1.0 to a
Cisco, you have to get patch 100941-02. Once it it installed, everything
works smoothly, as written in the documentation!
My sun is an SS2, running 4.1.2 (sun4c architecture). We have a
'Transfix' digital leased line. That is: synchronous serial line,
64kbps.
The problem without the patch is that everything seems to be OK, except
that the MTU given by a 'netstat -in' on device ppp0 is set to 0.
-- Alain Mellan <amellan@acri.fr>
3.9 use MacPPP 2.0.1 on non-US System 6 Macintoshes
The current MacPPP Version (2.0.1) works on System 6 only if the system
folder is called "System Folder". On non-US systems (e.g. German
systems, where it is called "Systemordner"), MacPPP doesn't find some
file it needs. On System 7 Macs this problem isn't there. The workaround
is, to rename the system folder to "System Folder". Other programs will
ask the system, how the system folder is named, and continue to work.
Thanks to hn277pk@unidui.uni-duisburg.de (Peter Koch) for summarizing
this information to me, who never used a Macintosh (with the exception
of playing Shufflepack CafÈ once). *** Go back here. To the top page
here. Read on here.
4. MISC. PPP QUESTIONS WITH ANSWERS
Does somebody have a patent on PPP?
Is it possible to use PPP as link layer in ISDN?
My ppp does infinite configuration negotiation. What's wrong?
What is Asychronous HDLC?
4.1 Does somebody have a patent on PPP?
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386,comp.protocols.ppp
Subject: Re: Public domain PPP for SCO 2.0??
Date: 8 Dec 1992 06:04:52 GMT
[Somebody] wrote:
Doesn't matter. I just read (in another newsgroup) that DEC has a
patent on PPP, and is asking $5000 for a license. That means no public
domain PPP, and a rapidly increasing reluctance to support it from OEMs.
Stick with SLIP until something better comes along. This is *not*
true.
DEC has a patent application outstanding for the negotiation of a 48 bit
checksum which might be used in one of the option negotiation phases.
It is not an essential part of PPP; many implementations currently do
not use this little tiny algorithm in the way they work, and they work
just fine.
There is no indication that the 48 bit FCS will be accepted or
standardized on by the IETF - from my reading of the mailing lists
traffic that is unlikely at this point.
There are free PPPs and there will continue to be free PPPs. You will
also more likely buy PPPs as part of hardware you buy.
4.2 Is it possible to use PPP as link layer in ISDN?
[Somebody] wrote: Is it possible to use PPP as link layer in ISDN? If
yes, what about signalling? Do you need to combine PPP with the I.451
for basic call control? There are (at least) two drafts about IP over
ISDN links. (Please don't hesitate to search some up-to-date archive
site for newer versions of those documents.)
nic.nordu.net:/internet-drafts/draft-ietf-iplpdn-multi-isdn-01.txt
Determination of Encapsulation of Multi-protocol
Datagrams in Circuit-switched Environments
by Keith Sklower, Computer Science Department,University of California, Ber
keley
recommends "...limiting the choice of encapsulations to those
described in RFC 1294 (Frame Relay), RFC 1331 (PPP), and RFC 1356
(X.25)." and proposes out-of-band and in-band methods of determining
which encapsulation is used.
nic.nordu.net:internet-drafts/draft-ietf-pppext-isdn-01.txt
PPP over ISDN
by W A Simpson, Network Working Group
promotes PPP over HDLC over ISDN B-channels, or PPP over X25 over
ISDN D-channel, and allows for PPP over Frame Relay over the
D-channel.
A method is described to distinguish PPP from other frames by
in-band-inspection of the first packet received.
This review brought to you by
i.s.
4.3 My ppp does infinite configuration negotiation.
What's wrong?
4.3.1 [CABLE PROBLEM]
Each other month somebody posts a question which essentially is the one
above. It could, of course, be some very strange set of configurations
options which get the ppp to never terminate the negotiation process
(typical situations listed in further down). One other possibility was
seen many times on the derivatives of public ppp for suns, namely
pppd-1.01beta and dp-2.x.
Detailed symptoms (from a posting on the net, I saw similar logfiles
some months ago):
Typical debugging log output:
Dec 18 16:11:01 pppd[1694]: Starting ppp daemon version 1.0beta patchleve
l 1
Dec 18 16:11:01 pppd[1694]: warning... not a process group leader
Dec 18 16:11:01 pppd[1694]: pgrpid = 1694
Dec 18 16:11:01 pppd[1694]: popped stream module : ttcompat
Dec 18 16:11:01 pppd[1694]: popped stream module : ldterm
Dec 18 16:11:01 pppd[1694]: Using unit ppp0
Dec 18 16:11:01 pppd[1694]: hostname = Riga
Dec 18 16:11:01 pppd[1694]: connect: ppp0 /dev/ttya
Dec 18 16:11:01 pppd[1694]: fsm_sconfreq(c021): Sent id 1.
Dec 18 16:11:01 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 16:11:01 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:04 pppd[1694]: Alarm
Dec 18 16:11:04 pppd[1694]: fsm_sconfreq(c021): Sent id 2.
Dec 18 16:11:04 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:07 pppd[1694]: Alarm
Dec 18 16:11:07 pppd[1694]: fsm_sconfreq(c021): Sent id 3.
Dec 18 16:11:07 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.
... [lots of repetitious logging deleted] ...
Dec 18 17:02:24 pppd[1694]: Alarm
Dec 18 17:02:24 pppd[1694]: fsm_sconfreq(c021): Sent id 254.
Dec 18 17:02:24 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 17:02:26 pppd[1694]: Hangup
Dec 18 17:02:26 pppd[1694]: Untimeout 6194:16b38.
Dec 18 17:02:26 pppd[1694]: Setting itimer for 0 seconds.
Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ldterm
Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ttcompat
Dec 18 17:02:26 pppd[1694]: fcntl(F_SETFL, fdflags): Bad file number
The above final is caused by sending a SIGHUP to the pppd process
(however three successive SIGKILL's seem to be necessary to really get
rid of it).
The warning "not a process group leader" appears to be the innocent
result of a subtle coding bug, with no later effects, but I haven't
tried fixing it (variable "pid" uninitialized).
During all this, there seems to be no activity on the serial line, as
evident from an Interfaker(tm) breakout patch box. I was desperate
enough to lower the speed to 50 bps in order to verify this.
At the same time, "netstat -i" does show increasing figures for the
ppp0 interface in the "Opkts" column, but in no other column.
Solution: in all cases I could solve, it was a case of missing modem
control lines in the cables, leading to 'cts' floating to 'false'. The
LCP FSM happily sent configuration requests (they went to the serial
line driver buffer (and not out)), waited for an answer, got none, timed
out, and retried. After lots more of retries, especially on a big
machine, the send buffer finally does overflow, and ppp stops with an
error message.
You just have to connect 2,3,4,5,6,7,8 and 20 to the modem to repair it,
or to wire a reasonably complete null-modem cable. No, there is no
software hack, except when you patch the sources yourself. And that
would be a bad idea in my opinion. Even a small Sparcstation SLC can
overload any modem on a serial line, and you would get lots of
unnecessary packet drops because of that.
i.s.
4.3.2 [ADDRESS CONFIGURATION ERROR]
Each other month somebody posts a question which essentially is the one
above. It could, of course, be some very strange set of configurations
options which get the ppp to never terminate the negotiation process,
but this seems unlikely. This does happen under dp-2.3 [and probably
others, i.s.] when both sides of the link have differing opinions as to
what the 2 IP addresses should be. If the remote-address offered from
the remote side doesn't match the locally configured version then dp-2.3
will send back an REJ packet. The remote side will then resend the
original address again and the loop will continue.
To see if this is the case check the log for address REJ's. Then decode
the two hex addresses and print it out in the normal dot notation. This
is the IP address pair of what dp-2.x expected and what it got. Now
either reconfigure dp-2.x to expect this address or change the address
that the other side is sending.
Wolfgang Rupprecht
4.4 What is Asychronous HDLC?
It's HDLC with a character-by-character encapsulation, rather than a
bit-by-bit encapsulation. The details are discussed in the RFC1331,
appendix A. Basically, the flag character, the escape character and
(possibly) control characters are escaped by prepending the escape
character and XORing them with 0x20, while sync hdlc transparently
inserts '0' bits after sequences of 5 '1' bits to be sure to never
transmit the flag character in the frame.
A short description of the part of ISO 3309:1991 that describes async
(ISO calls it start/stop mode) HDLC is available with anonymous ftp from
ftp.uni-erlangen.de in pub/doc/ISO/english/async-HDLC.
5. FREE PPP SOFTWARE PACKAGES
Free PPP FOR SunOS 4.1.x
Free PPP for BSD
Free PPP for SVR4
Free PPP for MSDOS
Free PPP for AmigaOS
Free PPP for NeXT
Free PPP for Macintosh
Free PPP for Ultrix
Free PPP for Linux
5.1 free PPP FOR SunOS 4.1.x
5.1.1 PPP-2.1 FOR BSD, SUNOS 4.X AND ULTRIX
Author Paul Mackerras <paulus@cs.anu.edu.au>,
Brad Parker <brad@FCR.COM> and contributors
Ultrix port: sundstrom@stkhlm.enet.dec.com (Per
Sundstrom) and
robert@robur.slu.se (Robert Olsson)
Architectures Sunos 4.x at least on Sparc,
NetBSD at least on 80?86 and Amiga
Ultrix on DECstations
FTP archives dcssoft.anu.edu.au:/pub/ppp/ ppp-2.1.tar.gz
Also from merit.edu:/pub/ppp/sunos-new
Self-Description PPP version 2.1 is now available by anonymous FTP
from dcssoft.anu.edu.au, in file
/pub/ppp/ppp-2.1.tar.gz.
The Ultrix port ist included in the official port PPP-2.1...
Robert Olsson <Robert.Olsson@data.slu.se>
... The main change [of 2.0] from ppp-1.3.1 is that the new release
contains a substantially improved version of pppd.
New features in pppd include:
Vastly improved security and authentication features
Conforms to RFCs 1331, 1332, 1334
Reads options from files as well as the command line
Does proxy-ARP and default route creation if requested
Paul Mackerras <paulus@cs.anu.edu.au>
Comment ppp-1.3 included in NetBSD distributions;
ppp-2.0.4 is reported to work on NetBSD-Amiga,
NetBSD-Intel and SunOS-4.x-Sparc (did anybody try
NetBSD-Sparc?)
5.1.2 DP-2.3
Authors Kirk Smith , peter.galvaby@micromuse.ac.uk
and others
Features demand-dial, filtering, header compression,
server and client, scripting;
SunOS loadable modules partially supported
Comment basically dp-2.2-beta with typos corrected and
non-sun4c kernel
architecture supported (tested on sun4c, sun4m and
sun3
machines, but has problems on sun3x
architectures). It has a
configuration file, which tells where the other
configuration
files are. Loadable modules work as long as you
don't unload
them. Finally survives even talk(1) without
crashing the
machine. If you see older versions, especially
dp-2.0.tar.Z, toss them immediately!
Plans Solaris 2.1 (sunos 5.1) is supported in the
dp-3.0 version (see chapter SVR4).
Mailing list maintainer
ks@phoenix.acn.purdue.edu
Mailing-list dp-list@phoenix.acn.purdue.edu (don't send 'add'
or 'delete' requests here!!!
FTP archive
ftp@phoenix.acn.purdue.edu:pub/
5.1.3 PERKINS/CLEMENTS/FOX/CHRISTY PPP FOR SUNOS
Last version patch level 6 of 1991-10-04
Anonymous FTP [not cited to protect the innocent]
Comment should be considered out of date. You need at
least a special patch to fix
most of a memory leak, and might have other
problems. Successor
packages are dp-2.3/3.0 and
ppp-1.2.
5.2 free PPP for BSD:
5.2.1 PPP-2.1
see above.
5.3 free PPP for SVR4
5.3.1 ...FOR GENERIC SVR4
[det@hawkmoon.mn.org (Derek Terveer) was] "... contacted by the author
of the PPP for SVR4 package that I was distributing from my
mailserver@hawkmoon.mn.org and asked to stop. This package was an early
beta version that wasn't intended for general consumption. ..."
5.3.2 ...SUNOS 5.X/SOLARIS 2.X
dp-3.0 (Solaris 2.x version of dp-2.3)
dp-3.0 has been out for quite a while. It works with Solaris 2.1 (for
anyone foolish enough to still be running it), 2.2 and 2.3.
"...It is much more stable and better behaved than the Solaris 2.3 ppp
from Sun...." (Larry Williamson <larry@mitra.com>)
5.4 Free PPP for MSDOS
5.4.1 WG7J NOS (JNOS) PPP ADDITIONS:
Johan Reinalda (WG7J) did a lot of additions/improvements to the KA9Q
for MSDOS. One of them seems to be that PPP is working, finally. Get
version 1.08 and up.
Authors Phil Karn (KA9Q), Johan Reinalda (WG7J), with
additions from lots of others. PPP code written by
Katie Stevens of UC Davis, based on the original
implementation by Drew Perkins of CMU. Updated by
Bill Simpson and Glenn McGregor of the University
of Michigan.
Features server, client, scripting, redial,
Public FTP sites:
wg7j.ece.orst.edu:/public/108/
ucsd.edu:hamradio/packet/tcpip/wg7j/
speckled.mpifr-bonn.mpg.de:/pub/rhein.de/jnos*.exe [Executable; no
warranty; ATTENTION: THIS IS IN EUROPE!]
Comment There is a entry in the configuration recipes
section.
5.4.2 PPP PACKET DRIVER INTERFACE
Ftp archive merit.edu:pub/ppp/ncsappp.zip
Comment "I have also been able to use the NCSA telnet
packet driver,
however, I could not use ftp with that, so I
gave it up some months
ago."
kim@MorningStar.Com (Kim Toms)
I had no problems with it. For a solution to an
interoperability
problem, see above.
i.s.
Very incomplete features
client only
5.5 Free PPP for AmigaOS
5.5.1 AMIGANOS (KA9Q NOS PORT TO AMIGA)
Mailing-list-maintainer
amiga-slip-request@ccs.carleton.ca
FAQ posting comp.sys.amiga.datacomm, every 21 days
Author JOHN_H@fs2.mcc.ac.uk (John Heaton)
Public ftp archive ftp.demon.co.uk: /pub/amiga/setup/setupv4.lha
419364 bytes (Setup for newcomers;
Note that this contains some information which is
quite
specific for the demon.co.uk site only)
/pub/amiga/anos/anos29k.lha 196742 bytes (if you
already have an
earlier version of setup and just need AmigaNOS
2.9k. Also on
wuarchive.wus
tl.edu:/mirrors3/ka9q/amiga/anos29k.lha
Help File
wuarchive.wustl.edu:/sys
tems/amiga/incoming/text/AmigaNOS-help-V2.lha or
ftp.demon.co.uk:/pub/amiga/setup/AmigaNOS-help-V
2.lha
Comments AmigaNOS2.9k.lha contains PPP as well as SLIP.
Seems to be a
rfc1171 like implementation, enhanced with a
few rfc1331/2
features (like most other implementations I
know of)
5.5.2 PPP.DEVICE FOR SANA2 COMPATIBLE NETWORK PACKAGES
(AS225, AMITCP, ENVOY)
5.5.2.1 Kruse-PPP 1.0 evaluation version.
Author Holger Kruse <kruse@cs.ucf.edu>
Public FTP archive on Aminet:comm/net; ftp to e.g.
wuarchive.wustl.edu, cd to /pub/aminet and read
the instruction about the nearest mirror to you.
Status Demo-Version, with Asyncmap set to 0xFFFFFFFF.
For the full version see 7.1.1
Supports IPCP, is reported to work with AmiTCP-3.0 and AS225R2, claimed
to work with AmiTCP-2.3.
5.6 Free PPP for NeXT
Public ftp archive merit.edu:pub/ppp/next-ppp0.3.tar.Z
Author miron@cs.sfu.ca (Miron S. Cuperman)
Comment The author claimed: I heard that it doesn't work
with 3.0.
I haven't looked at it myself.
It's just a straight port of ppp-1.1. It works
with NeXTStep
2.1. It is based on the BSD part of ppp-1.1,
but with header
compression integrated. I'm not
currently supporting (or even using) it.
But dstrout@sun.REST.TASC.COM (Dave Strout via
MacPPP and Eudora) claims that:
"I have gotten the next-ppp0.2 to work just
fine under NeXTStep 3.0. I have only tried
MacPPP running against it, but telnet,
eudora, and GopherApp all work fine.
FTP does not work at 2400bps, but does at 9600.
dave."
told me that:
You state ppp-0.2 as being the latest version for
NeXTSTEP.
It isn't. ppp-0.3 is. However, ppp-0.3 and 0.2
don't run on
NeXTSTEP 3.1 or 3.2 (I believe), and both have
byte-ordering and
byte-alignment problems for White (intel)
hardware.
5.7 free PPP for Macintosh
-MacPPP 2.0.1 from Merit Network, Inc. and the University of Michigan
Author ljb@merit.edu (Larry Blunk)
Public ftp archive
merit.edu:pub/ppp/mac/...
Status
macppp2.0.1.hqx seems to be the newest binary release. There are
also sources. From the 'Installing MacPPP' document:
"...MacPPP 1.1 [as well as 2.0.1] is a Line Access Protocol (LAP mdev)
driver for MacTCP. This version does not support AppleTalk over PPP.
MacPPP requires MacTCP 1.1 or higher, Macintosh System 6.0.5 or
higher, and a Hayes-compatible modem for dial-in connections. You
can also use MacPPP over hardwired asynchrounous connections, ..."
Comment There's an entry in the configuration section
above. There are PostScript and text installation
documents at the ftp site. Although these date back to the 1.1.x
releases, they're still useful for installing MacPPP 2.0.1.
For a workaround for a MacPPP 2.0.1 on non-US System 6, look into
the configuration section, too
5.8 free PPP for Ultrix
ppp-2.1, see above.
5.9 free PPP for Linux
ALPHA PPP for Linux Version 0.2.1
linux-ppp-0.2.1.tgz kernel files + pppd source and binary
Authors Michael Callahan <callahan@maths.ox.ac.uk>
Al Longyear <longyear@netcom.com>
public ftp site ftp.gang.umass.edu, directory /user/michael
self-description Version 0.2.1 is meant for use with kernels 1.0.x
and 1.1.x.
6. UNCOMPLETE LIST OF FTP SITES FOR PPP STUFF, DOCS ETC.
try also the ftp sites mentioned above in the 'packages' section.
Merit PPP collection at merit.edu:/pub/ppp/
Ohio PPP collection at archive.cis.ohio-state.edu:/pub/ppp (lots of
software there is out of date, however; look into the packages
section for information on up-to-date versions of the software.)
KA9Q NOS collection at ucsd.edu:...
A list of AmiNET mirrors (for Amiga networking software) can be
obtained by ftp-ing to, e.g. ftp.etsu.edu, directory /pub/aminet, and
reading the README file found there.
7. COMMERCIAL PPP SOFTWARE PACKAGES
7.1 Amiga Inet
7.1.1 Kruse-PPP 1.0 keyfile version.
Author Holger Kruse <kruse@cs.ucf.edu>
Public FTP archive on Aminet; ftp to e.g. wuarchive.wustl.edu, cd to
/pub/aminet and read the instruction about the
nearest mirror to you. The necessary keyfile has
to be issued by the author; a registration form is
enclosed with the evalutation version (see
5.5.2.1).
Status Full Version, with configurable Asyncmap.
Supports IPCP, is reported to work with AmiTCP-3.0 and AS225R2, claimed
to work with AmiTCP-2.3.
7.2 MSDOS with and without MSWindows
7.2.1 COMMERCIAL PPP PACKAGES FOR MS-DOS AND MS-WINDOWS
This information orignally appeared in the December 7th, 1992 issue
of "Open Systems Today", a newspaper published by CMP Publications,
(516) 562-5882.
Each of these packages costs around $400 not including volume or other
discounts. Call the vendor for details.
Each of the packages is a complete TCP/IP stack with assorted client
programs, ftp, telnet, etc.., that run under MS-DOS and/or MS-Windows.
The TCP/IP client programs included in each package vary. Some use the
DOS command line (even under MS-Windows) while others have full Windows
GUI interfaces. A PPP client (but not server) is included with each of
these packages.
7.2.1.1. LAN WorkPlace for DOS 4.1 beta (see also 7.2.2)
Novell
USA: (801) 429-5588
Summary: This is an MS-DOS TSR (Terminate and Stay Ready) solution so it
runs under either MS-DOS or MS-Windows. It includes a program called
"DIALUP" that only allows connections at 8 bits, no parity. You can use
the public domain "kermit" program instead if you need 7 bits, parity
connections.
7.2.1.2. PC/TCP
FTP Software
USA: (508) 685-4000
Contact: info@ftp.com
Summary: PC/TCP is an MS-DOS TSR solution that had PPP long before it
was fashionable. Not surprisingly, it was the only non-beta product
available for this review.
Comment: PC/TCP 2.2 was shipped 24/25 March 1993 (information indirectly
through one of their customers.) I copy parts of the feature list:
1. Autoinstall/Autoconfig (graphical interface, easy install)
2. PCTCPNET (mount InterDrives from File Manager)
3. PCNFSD Print Support (multiple print redirection through PCNFSD)
4. Router Discovery - RFC 1256
5. 8K UDP Writes
6. WMSG (Demonstrates IP Multicast)
7. NFS/TCP Support
8. International Character Set Support / Names in InterDrive
9. International Character Set Support / Directory in InterDrive
10. MVSLogin Support for InterDrive
11. TN Mouse and light pen Support
12. VI Compression for both SLIP and PPP
13. WinSockAPI Meets Final Revision
14. Interdrive EMM Caching Support - use EMM for buffers
15. Inet - Serial line additions debug SLIP and PPP connections
16. Kerberos/Ktelnet
17. Kernel/Netbios Interactions imporved support for LANtastic, LAN MAN
7.2.1.3. Distinct TCP/IP 3.0 beta
Distinct Inc.
USA: (408) 741- 0781
Summmary: This is a Windows DLL solution so it only runs under MS-Windows
.
Nice scripting features and built-in support (stored configuration
strings, basically) for various modems.
7.2.1.4. Super-PPP for Windows 1.0 beta
Frontier Technologies Corp
USA: (414) 241-4555
Summary: This is a Windows DLL solution that is an optional component of
their Super-TCP for Windows product. Super-TCP comes in both TSR and
DLL flavors but the Super-PPP product is strictly DLL. Very configurable.
Performance notes: If you run PPP under MS-Windows, your performance will
suck (it might not work at all!) unless you have 16550A UARTs in your PC.
If you have an extra card slot, you can add two 16550A ports with the
DSP 550 card from STB Systems, (214) 234-8750. To find out what kind
of UARTs are in your PC, use the program "msd.exe" in your MS-Windows 3.1
install directory or retrieve the program
/published/open-systems-today/uarttype.zip from ftp.uu.net .
Older UARTs are the 8250 or the 16450. These UARTs will work ok under
MS-DOS. A fast CPU helps, though. No performance tests were run because
three of the four packages above are still in beta.
For more information, read the Open Systems Today article and stay
tuned to this FAQ.
7.2.2 MSDOS/NOVELL:
Novell now offers PPP support (asynchronous) in LAN WorkPlace for DOS
version 4.1, and PPP support for synchronous and T1 connections on
NetWare v3.11 servers in the MultiProtocol Router WAN Links option.
NetWare server support for the routing of IP and IPX protocols over
asynchronous dialup lines will be available sometime around mid-1993.
This is an excerpt from LWP41.TXT, a document describing LAN
WorkPlace for DOS v4.1 (the entire text can be found on
sjf-lwp.sjf.novell.com in ~/lwp4dos/lwp41.txt):
* SLIP (Serial Line Internet Protocol) and PPP (Point to Point
Protocol) support. SLIP and PPP support is provided in the form
of a custom ODI driver for LAN WorkPlace: SLIP_PPP.COM. This
driver allows the Novell TCP/IP Transport for DOS v4.1 to use
asynchronous connections for IP services required by DOS and
Windows applications. It supports the following:
- SLIP
- Compressed SLIP (C-SLIP) using Van Jacobson TCP/IP header
compression (as described in RFC-1144).
- PPP with support for Van Jacobson TCP/IP header compression
option negotiation and PAP (Password Authentication
Protocol) as described in RFC-1334.
- Support for National Semiconductor's 16550, 16550A, 16450
and 8250 UARTs (Universal Asynchronous Receiver
Transmitter). Use of a 16550 UART is strongly recommended
(and is required for use with Windows at speeds of 9600bps
or greater). NOTE: One can use the Microsoft Diagnostics
program supplied with Windows v3.1 (MSD.EXE) to determine
which type of UART is installed in a PC.
- Interface speeds up to 57,600 bps when used with a
V.32bis/V.42bis modem and 16550A UART.
brian@novell.com (Brian Meek) clarified on my request, that:
IP is the only protocol supported directly by the LAN WorkPlace
SLIP_PPP driver in this initial release. One can use the IPTUNNEL
LAN driver (also included in LAN WorkPlace) to encapsulate IPX in
UDP/IP and attach to a NetWare v3.11 server running a similar
driver. This "IP Tunneling" mechanism is described in RFC 1234.
Direct IPX support for this PPP driver will be added later, but
the current tunneling mechanism is presently more widely
applicable... since few (if any) PPP implementations are presently
available with support for IPX.
7.3 386/486 PC's with SCO Unix:
7.3.1 SCO UNIX ODT2.0 AND LATER FOR 386/486 PC'S CONTAINS PPP.
7.3.2 MORNING STAR PPP RUNS UNDER SCO UNIX AND ODT (SEE 7.4)
7.4 for lots of computers running some Unix derivate:
Morning Star PPP
Price: $795 (40% discount for .edu)
Supported systems: Sun 4, Sun 3, NeXT, DECstation, RS/6000, SCO
UNIX, ISC
UNIX, and Silicon Graphics (for an actual complete
list, look at self-description
.
Features
demand-dial, scripting, filtering, redial, header compression,
client, server, tunneling, extra escaping, the ability to work with
various keycard access systems that require user interaction during
the script
Self-description
Morning Star claims that their async PPP and SLIP run fine over
UNIX systems' native serial ports, with no additional hardware
required. For better performance, they recommend that users of
PC-based UNIX systems install either a serial interface card based
on the NS16550AFN UART, or a multiport "smart" card. They claim to
do async PPP and SLIP/CSLIP as fast as the underlying UNIX supports
(usually 38400), and to do sync PPP up to T1 (1.544Mb/s) or E1
(Euro-T1, 2.048Mb/s) over their SnapLink. They provide
dynamically-loadable modules for SunOS 4.1.* and NeXTStep 2.1 and
3.0, so users needn't even reboot during the installation process.
WWW
http://www.morningstar.com
FTP
ftp.morningstar.com ftp.uu.net:/vendors/MorningStar/
E-mail:
marketing@morningstar.com
7.5 for SUN computers running SunOS
7.5.2 BRIXTON PPP
Supported systems: Sun 4
Features: demand-dial
7.5.3 SUNLINK PPP 1.0
was announced in SunFLASH Vol 49 # 1 (January 1993)
Requires SPARC(R) system running Solaris(R) 1.x operating
environment and either SunLink HSI/S or SunLink
MCP.
Features supports only synchronous up to 2MB/s lines,
load-sharing, dynamic routing. Only the obsolete
RFC1171/2 standard, but should interoperate with
newer implementations.
Price $1,225 (media, doc, and RTU) [in the USA only]
Comment for a necessary patch, look at the
configuration section.
7.5.4 SOLARIS 2.3
A frequently asked question in this newsgroup is ``How can I get PPP
working on Solaris 2.x?'' If you're willing to wait a few weeks, Sun
will do it for you. On Tuesday, SunSoft announced that Solaris 2.3 will
contain PPP. The press release says that Solaris 2.3 ``will be
generally available in early November.''
eggert@twinsun.com (Paul Eggert)
The patch for the mishandling of Async control character mapping (in the
LCP and IPCP negotiation) for Solaris 2.3 is patch number 101425 (the
current revision level is -01). It should now be available from your
favorite Sun patchetorium (e.g. U.S. Answer Center, SunSolve,
SunService, etc.) This should allow you to interoperate with PPP that
weren't able to deal with this bug such as the Telebit Netblazers. It
also allows interoperation with versions of PPP that do not support IP
address negotiation.
therbert@r2d2.Eng.Sun.COM (Tom Herbert)
7.6 for NeXT
7.6.1 MORNING STAR PPP SEE 7.4
PPP hardware
8. PPP HARDWARE
8.1 Hardware that does async PPP
[Started by: emv@msen.com (Edward Vielmetti) and heavily edited, to include
information from the net, by i.s.]
This is a list of hardware that supports async PPP, in the form
of a terminal server or terminal server / router combination.
- Telebit Netblazer
Phone: +1 800 TELEBIT
ftp information from ftp.telebit.com
SELF-DESCRIPTION
Date: Tue, 3 Aug 93 23:55:49 -0700
From: cslater@mondavi.sunnyvale.telebit.com (Charlie Slater)
The NetBlazer supports 24 async lines. An individual line can be
run at 115.2Kbps. A benchmark by LANQUEST showed the NetBlazer
could run PPP on 24 async lines at 38.4Kbps. I don't know of any
customers who run exclusively PPP on 24 lines, but I know of several
that run mixtures of SLIP and PPP on 24 lines.
OPINION:
From: bjs@beach.cis.ufl.edu (Brian J. Smith)
Date: Fri, 27 Nov 92 23:35:18 GMT
A NetBlazer works flawlessly for remote site PPP/SLIP links. As a term
server it doesn't fit the bill. And a bit costly.
- Livingston Portmaster PM-11
ftp information from gator.netcom.com:/pub/livingston/
Livingston Enterprises, Inc: +1 510 426 0770
OPINION:
From: skl@wimsey.bc.ca (Samuel Lam)
Date: Sun, 29 Nov 1992 07:21:07 GMT
They have 10-, 20- and 30-port configurations. List prices
ranging from ~US$2.7K to ~US$3.8K. Contact <doug@livingston.com>
for more information.
- Xylogics MicroAnnex XL (8-16 ports - release 7.0 firmware)
- Xylogics Annex 3 (8-64 ports - release 7.0 firmware)
SELF-DESCRIPTION
From: carlson@xylogics.com (James Carlson)
Date: Fri, 30 Jul 1993 14:28:40 EDT
We don't have a sync PPP version yet, mostly because we don't support
sync serial yet. That is scheduled for the R8.1 release.
We have had async PPP since our R7.0 release in October 1992 for our
Annex 3 and Micro Annex XL platforms. PPP is not supported on the (now
obsolete) Annex 2 nor on the Micro Annex ELS.
The Annex 3 can be customer-upgraded from 8 to 64 async serial lines,
with full modem controls on each line, and two to three i376 processors.
(The i376 is an embedded version of the 80386 which does not have an
MMU.) The motherboard has one i376 and each serial card (maximum two)
has one. Packet routing and user-level functions are handled on the
motherboard, while framing and PPP/SLIP link-level processing are done
on the serial cards.
OPINION
From: bjs@beach.cis.ufl.edu (Brian J. Smith)
Date: Fri, 27 Nov 92 23:35:18 GMT
I have been *VERY* happy with my Xylogics terminal servers I have to Anne
x
II's and a Annex 3. They were designed for the Unix type person, and tak
e
2 mins to get working on the network. Port configuration will take longe
r,
but normally you only have a few sets of configurations "modem dialin hig
h
speed" etc. Two thumbs up to this company, now if they didn't cost so
much. :) :)
- Datability VCP 200/300 ( ??? )
From: bjs@beach.cis.ufl.edu (Brian J. Smith)
Date: Fri, 27 Nov 92 23:35:18 GMT
I tested one of these, they come in 8-16 port configurations, a TCP or LA
T or
TCP/LAT version. Very VMS like, I would guess a off spring of DECservers
.
Cheaper than the Xylogics in Price. Didn't fit my feel due to the VMSish
help and commands.
- 3com CS/2100 (10 lines max)
[Was mentioned in a posting of Peter Galbavy, summarizing suggestions
other ppl. made to him about ppp-capable terminal servers. i.s.]
8.2 Hardware that supports sync PPP
Newsgroups: comp.protocols.ppp
Original-From: emv@msen.com (Edward Vielmetti), but heavily edited by i.s.
Note that sync PPP is rather well established and it's not surprising
to see lots of vendors using it as their only sync serial line
protocol. Various folks do various of the configuration options,
anywhere from a full implementation to very bare bones.
The price point is arbitrary. These are list prices for the cheapest
box that has at least 1 sync PPP port that runs at 56 kb/sec plus one
ethernet. Prices approximate, your milage may vary, contact your
vendor for details.
- Cisco
E-mail: sales@cisco.com
- Telebit Netblazer
Phone: +1 800 TELEBIT
E-mail: ...@telebit.com
NS2-1ESN + SYN35 two EIA-232 SYNC ports and two V.35 sync ports
NB40 + 2 * SYN232 + SYN35 + SYN530 + SYN449 total of 10 sync ports
(4 EIA-232, 2 V.35 ports, 2 EIA-530 ports, 2 EIA-422/449)
SELF-DESCRIPTION
Date: Tue, 3 Aug 93 23:55:49 -0700
From: cslater@mondavi.sunnyvale.telebit.com (Charlie Slater)
As of this February (93), the NetBlazer/40 supports up to 10 sync ports.
All can be run at 128Kbps and several can be run at 2Mbps (I don't have
any field or independent test data on how many can be run at 2Mbps, but I
think that the answer is at least 2).
- Livingston
E-Mail: ...@livingston.com
IR-4 1 ethernet + 4 56K + 1 RS-232
- Morning Star SNAPlink
E-Mail: marketing@morningstar.com
SnapLink SCSI-attached serial interface for Unix systems
1 T1 + 2 56K, RS-232 or RS-449
HDLC driver for sun4c ttya and ttyb included with PPP software. Works
only with SunOS "haven't been able to extract the information from
Sun that we need to make it work under SunOS 4.1.* or Solaris 2.*.
The HDLC driver works on NeXTs under NeXTStep 2.[12], but because of
NeXTStep's interrupt structure, we can only get it up to 19200 sync.
It's also available from ftp.morningstar.com:pub/tools/sun-hdlc.tar.Z.
It started as something from one of Torben Nielsen 's grad students,
and we're required to pass along any changes we make to it. We hope
that if someone gets it working under 4.1.*, they'll be nice enough to
pass their changes along too."